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Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 
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Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The IETF Trust (2007). 

Abstract 
This document defines a new optional Intermediate System to 
Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple 


sub-TLVs, which allows a router to announce its capabilities within 
an IS-IS level or the entire routing domain. 
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Les 


Ls. 


Introduction 


There are several situations where it is useful for the IS-IS [IS-IS] 
[IS-IS-IP] routers to learn the capabilities of the other routers of 
their IS-IS level, area, or routing domain. For the sake of 
illustration, three examples related to MPLS Traffic Engineering (TE) 
are described here: 


1. Mesh-group: the setting up of a mesh of TE Label Switched Paths 
(LSPs) [IS-IS-TE] requires some significant configuration effort. 
[AUTOMESH] proposes an auto-discovery mechanism whereby every 
Label Switching Router (LSR) of a mesh advertises its mesh-group 
membership by means of IS-IS extensions. 


2. Point to Multipoint TE LSP (P2MP LSP). A specific sub-TLV 
([TE-NODE-CAP]) allows an LSR to advertise its Point To Multipoint 
capabilities ([P2MP] and [P2MP-REQS]). 


3. Inter-area traffic engineering: Advertisement of the IPv4 and/or 
the IPv6 Traffic Engineering Router IDs. 


The use of IS-IS for Path Computation Element (PCE) discovery may 
also be considered and will be discussed in the PCE WG. 


The capabilities mentioned above require the specification of new 
sub-TLVs carried within the CAPABILITY TLV defined in this document. 


Note that the examples above are provided for the sake of 

illustration. This document proposes a generic capability 
advertising mechanism that is not limited to MPLS Traffic 

Engineering. 


This document defines a new optional IS-IS TLV named CAPABILITY, 
formed of multiple sub-TLVs, which allows a router to announce its 
capabilities within an IS-IS level or the entire routing domain. The 
applications mentioned above require the specification of new sub- 
TLVs carried within the CAPABILITY TLV defined in this document. 


Definition of these sub-TLVs is outside the scope of this document. 
1. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC-2119]. 
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2. IS-IS Router CAPABILITY TLV 


The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type, 
1 octet that specifies the number of bytes in the value field, anda 
variable length value field that starts with 4 octets of Router ID, 
indicating the source of the TLV, and followed by 1 octet of flags. 


A set of optional sub-TLVs may follow the flag field. Sub-TLVs are 
formatted as described in RFC 3784 [IS-IS-TE]. 


TYPE: 242 
LENGTH: from 5 to 255 
VALUE: 


Router ID (4 octets) 
Flags (1 octet) 
Set of optional sub-TLVs (0-250 octets) 


Flags 
OMT 3234. 67 
t-t-t-t+-t+-t+-t+-4+-4+ 
| Reserved |D|S| 
t-t-t-t+-t+-4+-4+-4+-4+ 


Currently two bit flags are defined. 


S bit (0x01): If the S bit is set(1), the IS-IS Router CAPABILITY TLV 
MUST be flooded across the entire routing domain. If the S bit is 
not set(0), the TLV MUST NOT be leaked between levels. This bit MUST 
NOT be altered during the TLV leaking. 


D bit (0x02): When the IS-IS Router CAPABILITY TLV is leaked from 
level-2 to level-1, the D bit MUST be set. Otherwise, this bit MUST 
be clear. IS-IS Router capability TLVs with the D bit set MUST NOT 
be leaked from level-1 to level-2. This is to prevent TLV looping. 


The Router CAPABILITY TLV is OPTIONAL. As specified in Section 3, 
more than one Router CAPABILITY TLV from the same source MAY be 
present. 


This document does not specify how an application may use the Router 


Capability TLV and such specification is outside the scope of this 
document. 
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3. Elements of Procedure 


A router that generates a CAPABILITY TLV MUST have a Router ID that 
is a 32-bit number. The ID MUST be unique within the IS-IS area. If 
the router generates any capability TLVs with domain flooding scope, 
then the ID MUST also be unique within the IS-IS routing domain. 


When advertising capabilities with different flooding scopes, a 
router MUST originate a minimum of two Router CAPABILITY TLVs, each 
TLV carrying the set of sub-TLVs with the same flooding scope. For 
instance, if a router advertises two sets of capabilities, Cl and C2, 
with an area/level scope and routing domain scope respectively, Cl 
and C2 being specified by their respective sub-TLV(s), the router 
will originate two Router CAPABILITY TLVs: 


- One Router CAPABILITY TLV with the S flag cleared, carrying the 
sub-TLV(s) relative to Cl. This Router CAPABILITY TLV will not be 
leaked into another level. 


- One Router CAPABILITY TLV with the S flag set, carrying the sub- 
TLV(s) relative to C2. This Router CAPABILITY TLV will be leaked 
into other IS-IS levels. When the TLV is leaked from level-2 to 
level-1, the D bit will be set in the level-1 LSP advertisement. 


In order to prevent the use of stale capabilities, a system MUST NOT 
use a Capability TLV present in an LSP of a system that is not 
currently reachable via Level-x paths, where "x" is the level (1 or 
2) in which the sending system advertised the TLV. This requirement 
applies regardless of whether or not the sending system is the 
originator of the Capabilities TLV. Note that leaking a Capabilities 
TLV is one of the uses that is prohibited under these conditions. 


Example: If Level-1 router A generates a Capability TLV and floods 
it to two L1/L2 routers, S and T, they will flood it into the 
Level-2 domain. Now suppose the Level-1 area partitions, such 
that A and S are in one partition and T is in another. IP routing 
will still continue to work, but if A now issues a revised version 
of the CAP TLV, or decides to stop advertising it, S will follow 
suit, but T will continue to advertise the old version until the 
LSP times out. 


Routers in other areas have to choose whether to trust T’s copy of 
A’s capabilities or S’s copy of A's information and, they have no 
reliable way to choose. By making sure that T stops leaking A’s 
information, this removes the possibility that other routers will use 
stale information from A. 
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In IS-IS, the atomic unit of the update process is a TLV -- or more 
precisely, in the case of TLVs that allow multiple entries to appear 
in the value field (e.g., IS-neighbors), the atomic unit is an entry 
in the value field of a TLV. If an update to an entry in a TLV is 
advertised in an LSP fragment different from the LSP fragment 
associated with the old advertisement, the possibility exists that 
other systems can temporarily have either 0 copies of a particular 
advertisement or 2 copies of a particular advertisement, depending on 
the order in which new copies of the LSP fragment that had the old 
advertisement and the fragment that has the new advertisement arrive 
at other systems. 


Wherever possible, an implementation SHOULD advertise the update to a 
capabilities TLV in the same LSP fragment as the advertisement that 
it replaces. Where this is not possible, the two affected LSP 
fragments should be flooded as an atomic action. 


Systems that receive an update to an existing capability TLV can 
minimize the potential disruption associated with the update by 
employing a holddown time prior to processing the update so as to 
allow for the receipt of multiple LSP fragments associated with the 
same update prior to beginning processing. 


Where a receiving system has two copies of a capabilities TLV from 
the same system that have different settings for a given attribute, 
the procedure used to choose which copy shall be used is undefined. 


4. Interoperability with Routers Not Supporting the Capability TLV 


Routers that do not support the Router CAPABILITY TLV MUST silently 
ignore the TLV(s) and continue processing other TLVs in the same LSP. 
Routers that do not support specific sub-TLVs carried within a Router 
CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs and 
continue processing those sub-TLVs that are supported in the Router 
CAPABILITY TLV. How partial support may impact the operation of the 
capabilities advertised within the Router CAPABILITY TLV is outside 
the scope of this document. 


In order for Router CAPABILITY TLVs with domain-wide scope originated 
by L1 Routers to be flooded across the entire domain, at least one 
L1/L2 Router in every area of the domain MUST support the Router 
CAPABILITY TLV. 


If leaking of the CAPABILITY TLV is required, the entire CAPABILITY 
TLV MUST be leaked into another level even though it may contain some 
of the unsupported sub-TLVs. 
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3% 


8. 


Security Considerations 


Any new security issues raised by the procedures in this document 
depend upon the opportunity for LSPs to be snooped and modified, the 
ease/difficulty of which has not been altered. As the LSPs may now 
contain additional information regarding router capabilities, this 
new information would also become available to an attacker. 
Specifications based on this mechanism need to describe the security 
considerations around the disclosure and modification of their 
information. Note that an integrity mechanism, such as the one 
defined in [RFC-3567] or [IS-IS-HMAC], should be applied if there is 
high risk resulting from modification of capability information. 


IANA Considerations 
IANA assigned a new IS-IS TLV code-point for the newly defined IS-IS 


TLV type named the IS-IS Router CAPABILITY TLV and defined in this 
document. The assigned value is 242. 
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